System for secure multi-protocol processing of cryptographic data

ABSTRACT

A general computing environment (GCE) determines request data comprising payload data and instruction data to use cryptographic functions in a secure computing environment (SCE). The SCE provides secure input and output devices, allowing secure presentation to a user and acquisition of user input. The SCE receives the request data and processes the payload data using the instructions in the instruction data to produce cryptographic output data. The request data may be determined using schemas that specify the formatting, grammar, and other attributes of data associated with a transaction that utilizes cryptographic functions. By using schemas and the request data, the SCE may support any protocol that uses the cryptographic functions supported by that SCE to compose cryptographic output. To enhance user comprehensibility and security, the SCE may securely replace some data with human readable text or images and present this as abstracted request data.

INCORPORATION BY REFERENCE

U.S. patent application Ser. No. 16/057,290 filed Aug. 7, 2018 andtitled “System for Secure Storage of Cryptographic Keys” is herebyincorporated by reference in its entirety.

U.S. patent application Ser. No. 16/440,870 filed Jun. 13, 2019 andtitled “Dynamic Off-Chain Digital Currency Transaction Processing” ishereby incorporated by reference in its entirety.

BACKGROUND

An increasing number of systems rely on cryptographic secrets, such asprivate keys, for operation. For example, these systems may be used tosecurely store data, identify a particular individual or item, exchangevalue, and so forth.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a system that utilizes a general computing environmentand a secure computing environment to provide secure multi-protocolprocessing of cryptographic data, according to one implementation.

FIG. 2 illustrates a block diagram of the device, according to oneimplementation.

FIG. 3 illustrates blockchain data, according to one implementation.

FIG. 4 illustrates block diagrams of data associated with operation ofthe system such as schema data and request data, according to oneimplementation.

FIG. 5 illustrates block diagrams of abstraction data and abstractedrequest data that may be used by a secure user interface to presentsecure output that facilitates user readability, according to oneimplementation.

FIG. 6 illustrates adding abstraction data to the system, according toone implementation.

FIG. 7 illustrates presentation of request data and abstracted requestdata by the secure user interface, according to one implementation.

FIG. 8 is a flow diagram of a process for processing transaction inputto determine formatted output data, according to one implementation.

While implementations are described herein by way of example, thoseskilled in the art will recognize that the implementations are notlimited to the examples or figures described. It should be understoodthat the figures and detailed description thereto are not intended tolimit implementations to the particular form disclosed but, on thecontrary, the intention is to cover all modifications, equivalents, andalternatives falling within the spirit and scope as defined by theappended claims. The headings used herein are for organizationalpurposes only and are not meant to be used to limit the scope of thedescription or the claims. As used throughout this application, the word“may” is used in a permissive sense (i.e., meaning having the potentialto), rather than the mandatory sense (i.e., meaning must). Similarly,the words “include,” “including,” and “includes” mean including, but notlimited to.

DETAILED DESCRIPTION

Cryptography and cryptographically based systems are critical to a widevariety of systems. For example, cryptography may be used to preventdisclosure of information to unintended parties, to provide digitalsignatures that assert the authenticity of a message, and so forth.Cryptographic data may include private keys used to provide a digitalsignature, to encrypt information, and so forth. The cryptographic dataand one or more data processing functions are used to compose a message.

Systems such as distributed ledgers (or “blockchains”) may utilizedigital signatures to sign such messages that represent blockchaintransactions that, if validly signed, would result in updates to thedistributed ledger that indicate transfers of tokens from one account toanother. At any given time, a token is only associated with onecryptographic key pair. In some implementations, tokens may be used torepresent assets. Blockchains provide for a decentralized, distributedtrustless system, allowing participants to transfer value, participatein smart contracts, and so forth. For example, cryptocurrencies such asBitcoin, Ethereum, Iota, Zcash, Monero, Cardano, and so forth utilizeblockchains to operate. Digital cryptographic signatures (signatures)are used to determine if a message describing a proposed transaction isauthentic, and whether the transaction is valid. A message is deemed tobe authentic if the corresponding signature was produced using aspecific private key. A transaction is deemed to be valid if the keypair is associated with sufficient balance as indicated in the globalledger or privilege as indicated in the global ledger to execute thetransaction on the global ledger. For example, a message describing atransaction may be digitally signed with a private key using acryptographic function. The private key is intended to remain known onlyby the party authorized to permit the transaction. Continuing theexample, a message describing a transaction to transfer a specificamount of cryptocurrency from a source address that is derived from thesigner's private key to a destination address may be digitally signed bythe holder of the source private key. The message is then sent to one ormore blockchain servers. A blockchain server receives the message andchecks the digital signature. If the digital signature is authentic andvalid, the blockchain server may proceed to process the message andcommit the data in the message into the data of the blockchain. In somesituations, the particular blockchain system may perform various checksprior to committing the data, such as waiting until a consensus amongother blockchain servers has been reached. These checks establish ashared set of conditions (such as ensuring sufficient balance of thecryptocurrency sender) and are outside the scope of the signatureitself.

A cryptographic system is generally deemed to be secure only so long asthe secrets that are used as inputs to the cryptographic functions aremaintained in secret. For example, Alice may use a private key valueknown only to her to produce signatures for her cryptocurrency. IfAlice's private key value (which is usually a very large, random number)is ever compromised, such as through physical or electronic theft,carelessness, and so forth, an adversary could then use that private keyvalue to generate authentic digital signatures. If this key wereassociated with cryptocurrency balances on one or more networks, signingtransactions to move those cryptocurrencies would be both authentic andvalid. As a result, the adversary could perform actions as if they wereAlice, including stealing the cryptocurrencies associated with herprivate key.

The resistance of a cryptographic system to attack is also proportionateto the size of the private key used. As a result, longer private keysare preferred. The private keys may also be random values. The length,random nature, and so forth may make it difficult or impossible for auser to remember a single private key. The situation becomes untenablewhen a user may have many private keys. For example, Alice may have aprivate key for her personal Bitcoin account, a private key for herpersonal Ethereum account, a private key for her business Ethereumaccount, and so forth.

Traditional systems have attempted to mitigate these problems by keepingthe private key data offline. Physical media such as paper or devicesthat are “air gapped” and do not remain connected to a network may beused. For example, a cryptocurrency user may print the private key onpaper and place it in a bank vault, or store the private key on aremoveable memory device. However, the paper can be stolen or destroyed.Removeable memory devices such as “flash drives” may fail, be damaged,be lost, or get stolen. However, by rendering the private keysinaccessible to a network, they become significantly harder to use.Additionally, physical theft still remains a possibility, and physicalloss due to fire, flood, or other disaster may result in loss of privatekeys stored using these methods. Such systems also impose significantphysical limitations. For example, the amount of private key data thatcan be printed on a sheet of paper is limited, as is the memory of asingle device.

A device may be used to provide secure storage of secrets such asprivate keys and their use to compose messages. A device may be placedat a facility, such as a user's home. For example, a device known as a“hardware wallet” or “cryptocurrency wallet” may be used to storesecrets, perform some predefined instructions using particularcryptographic functions, and so forth. Traditional devices suffer fromseveral drawbacks including limited operability with respect tocomposition and poor user interfaces that leave users susceptible tofraud or errors.

Many devices are limited in the number of different assets that they areable to simultaneously support because the composition of a message thatutilizes cryptographic functions are fixed within those devices. Forexample, traditional hardware wallets are limited in the number ofdifferent protocols they support to interact with their respectiveblockchains. Such limitations may result from variations present in thecomposition of messages that are compliant with those differentprotocols. For example, each protocol may have different informationbeing processed, may serialize information in different ways, may havedifferent ways of representing the same type of information such as asource address, and so forth. As a result, due to the limitedcomputational and memory resources of a traditional hardware wallet, theability to maintain information about how to process and presentinformation about these different protocols is limited. Without thisinformation, information about a transaction is likely incomprehensibleto a user. As a result, a significant possibility exists that a user maycomplete a transaction that differs from what they intended.

This limited ability to compose messages poses a substantial usabilityproblem as the number of assets utilizing cryptographic data continuesto grow, each potentially using a different protocol requiring differentfunctions to be performed to compose a message compliant with thatprotocol. For example, a hardware wallet that only supports theprotocols for three cryptocurrencies at any one time has very limitedutility to a user who is using four cryptocurrencies. At the time thisdisclosure was prepared, there were over 12,000 cryptocurrencies. Manymore systems rely on cryptographic data, such as non-fungible token(NFT) blockchains, multi-factor authentication systems, and so forth.Many of these use different protocols, specifying different messageformat, grammar, syntax, and so forth. As a result, traditionalsolutions to provide for secure handling of cryptographic data areunable to facilitate interoperability with the every-growing number ofsystems using this cryptographic data. This substantially curtailsusability of these traditional devices.

Described in this disclosure are techniques that allow for a device thatincludes a secure computing environment (SCE) to compose at least acryptographically secure portion of messages for an extremely wide rangeof protocols and the composition of messages that are compliant withthose protocols. A general computing environment (GCE) may receivetransaction input data that indicates a transaction, such as a transferof value from one cryptocurrency account address to another. In oneimplementation, the same device may include both the SCE and the GCE. Inanother implementation, a first device may include the GCE, a seconddevice includes the SCE, and the two devices are in communication withone another. For example, the first device that includes the GCE maycomprise a cellphone, laptop, tablet computer, or other device that isin communication with the second device that includes the SCE. In oneimplementation, a browser extension, mobile application, or other moduleexecuting on the GCE may use an application programming interface (API)to interact with the SCE.

The GCE maintains schema data that provides information about therequirements for protocols that are supported by the SCE. Theinformation in the schema may include one or more of message format,grammar, syntax, and so forth. A protocol may be deemed to be supportedif the underlying SCE is able to perform the functions required tocompose at least a cryptographic portion of a message associated withthat protocol. For example, if the protocol for the (fictional example)“XKC” cryptocurrency uses the Keccak256 algorithm and the SECP256k1 ECCsigning curve to compose a message, and the SCE is able to perform thesefunctions, the SCE may be deemed to support transactions on the XKCblockchain. Continuing the example, if the “XKC” protocol requiressigned messages to begin with “helloworld” the schema data associatedwith “XKC” would include this information.

In some implementations, responsive to a message from a previouslypaired device, one or more of a version number, smart card identifier,list, or other information that is indicative of the functions supportedby the SCE may be returned to the paired device.

The transaction input data is processed to determine request data. Therequest data may comprise payload data and instruction data. The payloaddata comprises the input to be operated on to compose a message, and theinstruction data specifies a set of instructions that operate on thepayload to compose a message that is compliant with one or moreprotocols. The payload data and the instruction data are suitable forprocessing by the SCE. In some implementations, the schema data may beused to process the transaction input data and determine the requestdata. The instruction data may comprise a script that complies with aspecified scripting language. In some implementations, the request datamay be formatted as a concise binary object representation (CBOR). Therequest data is then sent to the SCE. For example, the GCE may use anAPI to interact with the SCE.

Within the SCE, the request data is processed to compose at least aportion of a message. For example, responsive to the instructionsprovided in the instruction data and operating on one or more values inthe payload data, cryptographic output data is generated. Continuing theexample, this may include performing one or more operations such asserialization, cryptographic signing operations, memory operations,cryptographic transformation operations, and so forth. In someimplementations, the instruction data may comprise a script, and theprocessing of the instruction data may comprise an interpreter moduleprocessing the script. In some implementations, the SCE may utilize astack-based architecture in which static buffers are specified to limitpotential adverse exploits of arbitrary code execution. As discussedbelow, a secure output device of the SCE may be used to presentinformation about the request data. This allows the user the opportunityto view details about the request data. A secure input device of the SCEmay be used to accept input that is indicative of approval to proceedwith processing the request data using the SCE to determine thecryptographic output data. The resulting cryptographic output data maybe returned to the GCE.

Based on the schema data, the GCE may then process the cryptographicoutput data to determine formatted output data. Continuing the example,the formatted output data may comprise the cryptographic output dataafter having been rearranged, reformatted, or otherwise processed tocomply with the desired protocol, such as the “XKC” protocol. Thisformatted output data may then be sent to a blockchain server or otherdevice for further processing, such as inclusion in the blockchain as afinalized transaction.

By using these techniques, the system is able to process a transactionin any protocol that utilizes functions available within the SCE. Thismay also reduce the necessary cost or complexity of one or more portionsof the SCE. For example, compared to other approaches, by using the GCEto generate request data, and the SCE to process the request data, anSCE with lesser memory requirements and corresponding lower cost may beused. Continuing the example, an application programming interface (API)call may be made by the GCE to the SCE. In another example, by using theGCE to generate the request data, the SCE may be less complex, lessexpensive, consume less electrical power, and so forth. Continuing theexample, the functions associated with composition may be performed by aprocessor within a smart card.

The usability and security of a device may also be improved by providingmore robust and user-friendly information with a secure user interface.The SCE may include secure input/output (I/O) devices, such as atouchscreen that includes a display and a touch sensor. The SCE maypresent information about a pending transaction represented by therequest data on the display to allow a user to confirm the transaction.If the user agrees to process the pending transaction, secure user inputmay be acquired using the touch sensor and confirmed as valid input. Forexample, the user may enter a passcode value. If the entered passcodevalue matches a passcode previously stored in the SCE, the input may bedeemed to be valid input. Responsive to the valid input, the SCE maycomplete the processing to determine the cryptographic output data.

However, improper transactions may result if a user is mistaken ormisled to approve a transaction that differs from their intention. Theinformation associated with cryptographic data is seldom user-friendly.For example, cryptocurrency addresses may be long strings of nonsensicalvalues to a human user. Many users would find it impossible to memorizethese addresses, much less confirm their accuracy. For example, arethese two addresses the same?

(Address 1) “0x4371a3a44435332c36ea634ed4c5b29dfcc3c890”

(Address 2) “0x4371a3a44435332c36ee634ed4c5b29dfcc3c890”

Address Example 1

If a user is conducting a transaction involving cryptographic data,assurance that they are performing the intended transaction is useful.Aside from keys, hashes, and other values, with over 12,000cryptocurrencies, it may be problematic to remember or even discern adifference between “XKC” and “XKD” as presented on a display,particularly if the display is small, the font is difficult to read, andso forth. This problem is exacerbated if additional language glyphs areused. For example, a user who reads only English may not readilyappreciate the difference between two glyphs in Hangul, such as:

(Hangul 1)

(Hangul 2)

Glyph Example 1

As described in this disclosure, abstraction data may be used to processthe request data and determine abstracted request data. The abstractiondata may be stored within the SCE and provides an association betweenparticular data that may be present in the request data andpredetermined or programmatically determined data suitable for userpresentation. For example, the cryptocurrency identifier of “XKC” may beassociated with “XKCoin” and a corresponding logo. During presentationon the secure output device, instead of only the text “XKC” the displaymay show “XKCoin” and the corresponding logo. Similarly, specifiedaddresses may be replaced with specified strings, such as “Blake'sAccount” for presentation on the secure output device. As a result,presentation using the abstracted request data provides a more“user-friendly” output that is more meaningful to the user and improvesthe ability of a user to determine if the transaction is what theyintend. As a result, overall assurance in operation of the system isimproved. The abstraction data may be provided from an external source,entered using the secure input device, and so forth.

By using the techniques and systems described in this disclosure, secureprocessing of cryptographic data is facilitated. The use of the schemadata and request data allows a variety of different cryptographicprotocols to be supported by a single SCE.

Illustrative System

FIG. 1 depicts a system 100 comprising a device 110 that utilizes ageneral computing environment (GCE) 120 and a secure computingenvironment (SCE) 140 to provide secure multi-protocol processing ofcryptographic data, according to one implementation.

The GCE 120 includes a processor, memory, and a network interface. TheGCE 120 is discussed in more detail with regard to FIG. 2 . Incomparison, the SCE 140 may include one or more of a dedicated processoror cryptoprocessor, and also includes secure encrypted memory, inputdevices, output devices, and tamper detection devices orcountermeasures. The SCE 140 is discussed in more detail with regard toFIG. 2 .

The SCE 140 may include, or have an interface allowing connection to,one or more smart cards 104. The smart card 104 may include secureencrypted memory, a cryptoprocessor, antitamper devices, and so forth.Cryptographic data or other secrets, such as one or more private keysmay be stored in the secure encrypted memory. The device 110 may allowfor secrets such as private keys to be stored within the SCE 140,including the secure encrypted memory of the smart cards 104 connectedthereto.

The smart card 104 may comprise secure encrypted memory that is securedusing a physically unclonable function (PUF), with the PUF beinginherent to that individual smart card 104. The smart card 104 isdiscussed in more detail with regard to FIG. 2 . In someimplementations, the smart card 104 may be a removeable device, may be anon-removeable device, or may otherwise be integrated into the SCE 140.

The SCE 140 utilizes a secure operating system (OS) and implementscontrols over transfer of data to the GCE 120. In addition to beingseparate from the GCE 120, the SCE 140 may respond to attempts tocompromise the system. For example, an unauthorized communication withthe SCE 140 may result in the contents of the secure encrypted memorybeing erased. In another example, an attempt to physically tamper withthe SCE 140 may be determined by one or more tamper detection devices.Upon determining the physical tamper attempt, the SCE 140 may erase thecontents of the secure encrypted memory, self-destruct, or take otheractions.

In some implementations, the SCE 140 may use one or more stack(s) 142.These stack(s) 142 may comprise one or more static buffer(s) 144. Thestack(s) 142 may be predefined, with specified static buffer(s) 144 suchas a data payload buffer 144(1), a stack buffer 144(2), a workingregister buffer 144(3), and so forth. The static buffers 144 may be thesame size, or may differ in size from one another. The buffers areconsidered static if their size is specified in advance and may not bechanged during processing of request data 132. The enforcement ofpredefined static buffers 144 may be used to mitigate or eliminateadverse execution of arbitrary code included in the SCE 140. In otherimplementations, other techniques may be used instead of, or in additionto, the static buffers 144. For example, a shadow stack may bemaintained and used.

To further maintain security, the SCE 140 or other components, such asthe smart card 104, may be configured to preclude some operationsoutright. For example, the smart card 104 may be prohibited from sendinga secret 242 in cleartext. Such prohibitions may be enforced through theabsence of commands to perform such operations, through explicitinstructions, or a combination thereof.

Data and capabilities of the smart cards 104 may be accessed while thesmart card 104 is operating as part of the SCE 140. For example, thedevice 110 may connect to a smart card 104(1). Once connected, the SCE140 may utilize secrets stored in the secure encrypted memory of thesmart card 104(1), utilize cryptographic functions that acryptoprocessor of the card is capable of executing, and so forth.

The SCE 140 provides one or more secure input/output (I/O) devices 112that may be used to provide a secure user interface 114. For example,the SCE 140 may include a touchscreen that incorporates a display and atouch sensor, allowing for the presentation of data to a user 102 andacquiring input from the user 102. In some implementations, the inputdevice may acquire biometric data, including but not limited tofingerprint data, palmprint data, iris data, and so forth. The I/Odevices 112 allow the SCE 140 to accept input such as pairing codes,passcodes, biometric data, address data, abstraction data, or other datain a way that is deemed highly secure and is independent of the networkthat the GCE 120 is connected to. For example, the input provided viathe secure input devices may be used for second factor verification.

The GCE 120 may include a user interface module 122. The user interfacemodule 122 may use one or more I/O devices, another device, or acombination thereof to present a user interface (not shown) to the user102. During operation, the device 110 may determine transaction inputdata 124. In one implementation, the transaction input data 124 isreceived from an external device via a communication interface of theGCE 120. In this implementation, the transaction input data 124 maycomprise a message that is compliant with a particular protocol. Forexample, the GCE 120 may be used to receive transaction input data 124representative of a transaction using the Ethereum blockchain.

In another implementation, the transaction input data 124 may begenerated based on user input acquired using a user interface presentedby the user interface module 122. For example, the user 102 may use theuser interface module 122 to enter information about a desiredtransaction.

A request processing module 126 in the GCE 120 accepts the transactioninput data 124 as input. Based at least in part on schema data 128 and,in some implementations, available secure functions 130, the requestprocessing module 126 determines request data 132. The schema data 128may be used to parse or otherwise process the transaction input data 124to determine particular fields, values, instructions, and so forth thatare expressed within the transaction input data 124. In someimplementations, the schema data 128 may specify the grammar, syntax,location, format, and so forth of various elements for a particularprotocol. The request data 132 may comprise a script that complies witha specified scripting language that may then be interpreted and executedby the SCE 140.

Available secure functions 130 may comprise information indicative ofthe capabilities of the SCE 140 or portions thereof to process data. Forexample, the SCE 140 may send to the GCE 120 information indicative of aset of data manipulation functions and cryptographic functions that aresupported by the smart card 104 that is currently connected to the SCE140. Different SCEs 140 or portions thereof such as different smartcards 104 may support different cryptographic functions, memoryoperations, and so forth.

In some implementations, the request processing module 126 may determineif the SCE 140 is able to support processing of a particular schema. Forexample, the transaction input data 124 may specify a transaction forthe XKC cryptocurrency. The schema data 128 associated with thecryptocurrency is retrieved and indicates that the Keccak256 algorithmis used. The request processing module 126 may check that the availablesecure functions 130 include the Keccak256 algorithm. If so, the processmay proceed. If not, an error notification may be presented.

The request data 132 comprises information, such as operations, inputs,and so forth that are associated with utilization of one or more of theavailable secure functions 130, use of the secrets 242, and so forth.The request data 132 may be represented with a specified formatting tobe processed by the SCE 140. For example, the request data 132 may beformatted as JavaScript Object Notation (JSON), concise binary objectrepresentation (CBOR), and so forth. This formatting may include somefeatures to improve intelligibility for human operators viewing thedata. As described below, the request data 132 may be presented by asecure output device of the SCE 140. Such presentation allows the user102 the opportunity to confirm the transaction is as intended or cancelthe transaction. A secure input device may be used to accept inputindicative of confirmation, modification, cancellation, and so forth.

Within the SCE 140, an abstract module 152 may use abstraction data 154to process the request data 132 and generate abstracted request data160. The abstracted request data 160, or a portion thereof, may bepresented using the secure user interface 114. The abstraction data 154specifies a relationship between first data and second data that isdeemed to be equivalent. For example, “XKC” may be associated with“XKCoin”. In one implementation, the abstract module 152 may accept therequest data 132 as input and execute one or more regular expressions(regexes) that are specified in the abstraction data 154 to produce theabstracted request data 160. The abstraction data 154 may specifyfields, data types, conditional tests, and so forth. For example, theabstraction data 154 may associate a first string with a second string.In another example, the abstraction data 154 may associate a conditionaltest if a first string has a first value and a second string has asecond value then a third value.

The abstraction data 154 may comprise one or more of general data 156 orspecific data 158. The general data 156 may comprise information that isapplicable to a plurality of users. For example, the general data 156may associate the identifiers for various cryptocurrencies to a longername. In another example, the general data 156 may associate theidentifiers with specific images, such as a logo. In someimplementations, as described below, the general data 156 may beprovided from a source external to the SCE 140. For example, a trustedparty may create general data 156 and distributed signed general data156 that may be imported into the SCE 140. If the signature is deemedvalid, the general data 156 may be stored and used within the SCE 140.In some implementations, the secure user interface 114 may be used toobtain valid secure input from the user 102 that authorizes the use ofthe general data 156.

The specific data 158 may comprise information that is applicable to aparticular user or set of users. For example, the specific data 158 mayassociate an account address with a text string such as “Blake'saccount”. In some implementations, the specific data 158 may begenerated, or confirmed, using the secure user interface 114. Forexample, the secure user interface 114 may present the account addressand a proposed text string. Valid secure input from the user 102 isreceived that authorizes the subsequent use of that specific data 158.

As mentioned above, the abstraction data 154 may specify conditions formultiple fields which must be met in part or in aggregate to determinethe abstracted request data 160. For example, the general data 156 mayspecify that for an Ethereum transfer several specified fields must havespecific values for the user 102 to trust that the message request theyare signing with the SCE 140 is indeed an Ethereum transfer. Forexample, a key derivation path is used to specify a signing key which isused in a hierarchically deterministic (HD) wallet. In someimplementations, the HD wallets may comply with one or more of theBitcoin Improvement Proposals (BIP) such as BIP32, BIP44, and BIP49. TheHD wallets may segregate keys used for various assets or blockchainsbased on the derivation path. A transaction involving Ethereum mayinvolve creating a field specifying that derivation path that isspecified by the tag “<derivationPath>” when making the request. Thegeneral data 156 may specify that to determine abstracted request data160 that specifies “Ethereum transaction” the value associated with thetag “<derivationPath>” would be required to have a value of“m/44′/60′/0′/0/0” specifying that derivation path. In other examples,other protocols may specify chain identifiers (chain IDs) to distinguishbetween a mainnet that implements functionality for users and testnetsthat is used to test functionality. In one example involving Ethereum,the request data 132 may include a field called “<chainId>” which hasthe value of “1”, indicating a mainnet chain.

In some implementations, the GCE 120 may utilize a value within aspecified field to refer to a particular set of functions or operations.For example, the transaction input data 124 may have a field“<RequestData>” with a value of “EthereumTransfer” that refers to a setof available secure functions 130 to complete an Ethereum transfertransaction. The request data 132 and resulting abstracted request data160 may include the text “Ethereum Transfer” if all of the associatedconditions specified by the abstraction data 154 correspond to therequest data 132 provided.

In some implementations, data indicative of a failure of the requestdata 132 to satisfy one or more of the conditions specified by theabstraction data 154 may be presented. For example, if the request data132 specifies a chain ID indicative of a testnet, the secure userinterface 114 may present “WARNING—TestNet Transaction”.

A secure user interface (UI) module 162 provides the secure userinterface 114. For example, the secure UI module 162 may execute withinthe SCE 140, using secure I/O devices 112. The secure UI module 162 mayprovide secure user output 164, such as presenting at least a portion ofone or more of the abstracted request data 160, the request data 132, orother information or user interface elements using the secure outputdevice(s). By providing the secure user interface 114, the system 100allows the user 102 to confirm that the transaction is as intended. Thismitigates problems associated with the user 102 approving a transactionthat differs from what they intended. For example, by presentinginformation about the actual transaction to be performed, the user 102may avoid inadvertently cryptographically signing data that differs fromtheir expectation.

The secure UI module 162 may be used to determine secure user input 166,such as input acquired using the secure input devices 112. In someimplementations secure user input 166 may be deemed to be valid uponentry of a passcode, biometric input, and so forth.

In some implementations, the transaction input data 124 may omit someinformation, or the user 102 may choose to change some part of theinformation that was received in the request data 132. For example, thetransaction input data 124 may not specify a source account for atransfer. In another example, the transaction input data 124 may specifya particular value to be transferred. In any event, the secure UI module162 may be used to present one or more of the abstracted request data160 or the request data 132. The secure user interface 114 may be usedto accept secure user input 166 to modify the request data 132 asoriginally received by the SCE 140. For example, if no source account isspecified, the user 102 may be prompted through the secure userinterface 114 to select a source account. In another example, the user102 may decide to change the value of the transaction. Based on thesecure user input 166, the resulting request data 132 may then beprocessed by a cryptography module 168.

The SCE 140 includes the cryptography module 168. The cryptographymodule 168 performs one or more cryptographic functions. Thesecryptographic functions may include, but are not limited to,cryptographic signing operations, memory operations, cryptographictransformation operations, and so forth. For example, cryptographicsigning operations may accept input data and a private or public key andproduce as output a digital signature. In another example, memoryoperations may comprise performing one or more mathematical operationssuch as addition, subtraction, division, memory manipulations such asconcatenation, length determination, and so forth. In yet anotherexample, cryptographic transformation operations may include encryption,decryption, hashing, and so forth. The cryptographic module 168 maysupport symmetric key encryption, public/private key encryption, and soforth. In some implementations, one or more of the cryptographicfunctions may be performed at least in part by the smart card 104. Forexample, a cryptographic processor (cryptoprocessor) on the smart card104 may be used to generate a signature.

The cryptography module 168 processes the request data 132 orinformation based thereon, such as the abstracted request data 160, anddetermines cryptographic output data 170. For example, the cryptographymodule 168 may use the payload data 134 as input and perform one or moreoperations on that input as specified by the instructions in theinstruction data 136 to compose the cryptographic output data 170.

The cryptographic output data 170 may be represented with a specifiedformatting for subsequent processing by the GCE 120. For example, thecryptographic output data 170 may be formatted as JSON, CBOR, and soforth. The cryptographic output data 170 is then sent to the GCE 120.The SCE 140 is discussed in more detail with regard to FIG. 2 .

The GCE 120 receives the cryptographic output data 170 and, based on oneor more of the transaction input data 124 or the schema data 128,determines formatted output data 182. For example, the transaction inputdata 124 may specify, or may be used to determine, a first protocol forthe formatted output data 182. Responsive to this, the output processingmodule 180 uses the schema data 128 to format the cryptographic outputdata 170 consistent with the first protocol. The output processingmodule 180 may perform various operations such as populating a templatespecified by the schema data 128 with information included in thecryptographic output data 170. For example, a predefined header stringmay be prepended to the cryptographic output data 170.

The formatted output data 182 may then be used. For example, the GCE 120may use a network 190 to send the formatted output data 182 to ablockchain server(s) 192. The blockchain server(s) 192 may process theformatted output data 182 and perform one or more operations withrespect to blockchain data 194. In other implementations otheroperations may be performed. For example, the formatted output data 182may comprise a digitally signed token used as part of a multi-factorauthentication system that is sent to a device requesting thatauthentication.

In some implementations, the cryptographic output data 170 may besuitable for use without subsequent processing by the output processingmodule 180. In such implementations, the formatted output data 182 maybe omitted and the cryptographic output data 170 may be used instead.

By using the systems and techniques described in this disclosure, theSCE 140 is able to support many different protocols that utilizefunctions supported by the SCE 140. The manipulations of cryptographicdata are maintained within the SCE 140, providing a high level ofassurance as to the security of the secrets and operations therein.

As described below, in some implementations, one or more of thefunctions or hardware described may be consolidated into a singledevice. For example, a smartphone may include an embedded secureencrypted memory equivalent to the smart card 104, include a securecomputing environment (SCE), and so forth.

FIG. 2 illustrates a block diagram 200 of the device 110, according toone implementation.

The device 110 may include a power supply 202. For example, the powersupply 202 may transform alternating current at a first voltage obtainedfrom a household outlet to direct current at a second voltage. In someimplementations other devices may be used to provide electrical power tothe device 110. For example, power may be provided by wireless powertransfer, batteries, photovoltaic cells, capacitors, fuel cells, and soforth.

The device 110 may comprise a general computing environment (GCE) 120.The GCE 120 may include one or more hardware processors 206 (processors)configured to execute one or more stored instructions. The processors206 may comprise one or more cores. The processors 206 may includemicrocontrollers, systems on a chip, field programmable gate arrays,digital signal processors, graphic processing units, general processingunits, and so forth. One or more clocks 208 may provide informationindicative of date, time, ticks, and so forth.

The GCE 120 may include one or more communication interfaces 210. Thecommunication interfaces 210 enable the GCE 120, or components thereof,to communicate with other devices or components. The communicationinterfaces 210 may include one or more of Inter-Integrated Circuit(I2C), Serial Peripheral Interface bus (SPI), Universal Serial Bus (USB)as promulgated by the USB Implementers Forum, RS-232, Ethernet, Wi-Fi,Bluetooth, Bluetooth Low Energy, ZigBee, or long-term evolution (LTE),and so forth. For example, the GCE 120 may include a Wi-Fi interfacethat allows the device 110 to communicate with the network 190, a Zigbeeinterface that allows the device 110 to communicate with other devices,and so forth.

The GCE 120 may include one or more I/O devices 212. The I/O devices 212may include input devices such as one or more of a switch, keyboard, ortouch sensor, and so forth. The I/O devices 212 may also include outputdevices such as one or more of a light, speaker, or display, and soforth. In some embodiments, the I/O devices 212 may be physicallyincorporated within the device 110 or may be externally placed.

As shown in FIG. 2 , the GCE 120 includes one or more memories 214. Thememory 214 may comprise one or more non-transitory computer-readablestorage media (CRSM). The CRSM may be any one or more of an electronicstorage medium, a magnetic storage medium, an optical storage medium, aquantum storage medium, or a mechanical computer storage medium, and soforth. The memory 214 provides storage of computer-readableinstructions, data structures, program modules, and other data for theoperation of the GCE 120. A few example functional modules are shownstored in the memory 214, although the same functionality mayalternatively be implemented in hardware, firmware, or as a system on achip (SoC).

The memory 214 may include at least one operating system (OS) module216. The OS module 216 is configured to manage hardware resource devicessuch as the communication interfaces 210, the I/O devices 212, andprovide various services to applications or modules executing on theprocessors 206. For example, the OS module 216 may implement a variantof the Linux operating system, such as FreeBSD. In otherimplementations, other operating systems may be used.

The memory 214 may store one or more of the following modules. Thesemodules may be executed as foreground applications, background tasks,daemons, and so forth. For example, the memory 214 may store acommunication module 218 and one or more other modules 220. Thecommunication module 218 may be configured to use one or more of thecommunication interfaces 210 to facilitate communication between otherdevices and the SCE 140. For example, the communication module 218 mayuse a network interface to establish a connection to a WiFi wirelessaccess point and exchange data with another device 110, blockchainservers 160, reputation servers, and so forth. The communication module218 may facilitate communication between the SCE 140 and other devices.In some implementations the communication module 218 may provide forencrypted communications with the network interface. The OS module 216,the communication module 218, or other modules 220 may provideadditional functions such as network security, denial of service, attackmitigation, port scanning detection, and so forth. In the event apotential attack is detected, the GCE 120 may take mitigating actions.For example, the GCE 120 may temporarily disconnect network access,acquire a new network address using a dynamic host configurationprotocol, suspend communication with the SCE 140, and so forth.

Also included within the memory 214 are the modules discussed withrespect to FIG. 1 , including the user interface module 122, the requestprocessing module 126, and the output processing module 180.

Also stored in the memory 214 may be a data store 222. The data store222 may use a flat file, database, linked list, tree, executable code,script, or other data structure to store information. The data store 222may include configuration data 224. For example, the configuration data224 may include connection parameters for the network interface. Otherdata 226 may also be stored in the memory 214. Also stored within thememory 214 is the data discussed with respect to FIG. 1 , including thetransaction input data 124, the schema data 128, the available securefunction(s) 130 information, the request data 132, and the formattedoutput data 182.

The device 110 comprises the secure computing environment (SCE) 150. TheSCE 140 may include one or more hardware processors 228 (processors)configured to execute one or more stored instructions. The processors228 may comprise one or more cores. The processors 228 may includemicrocontrollers, systems on a chip, field programmable gate arrays,digital signal processors, graphic processing units, general processingunits, and so forth. One or more clocks 230 may provide informationindicative of date, time, ticks, and so forth.

The SCE 140 may include one or more communication interfaces 232. Thecommunication interfaces 232 enable the SCE 140, or components thereof,to communicate with other devices or components. The communicationinterfaces 232 may include one or more of I2C, SPI, USB, RS-232, securedigital host controller (SDHC), smart card interface, or near-fieldcommunication (NFC) interface, and so forth. In some implementations,communication between the GCE 120 and the SCE 140 may be limited to aparticular communication bus, such as SPI or USB.

The SCE 140 may include one or more secure I/O devices 112. The secureI/O devices 112 may include secure input devices such as one or more ofa switch, keyboard, or touch sensor, and so forth. The secure I/Odevices 112 may also include secure output devices such as one or moreof a light, speaker, or display, and so forth. For example, the secureI/O devices 112 may include a touchscreen that incorporates a displayand a touch sensor, allowing for the presentation of data andacquisition of input. These secure I/O devices 112 may be constrainedsuch that they may only be accessed by the SCE 140, and not the GCE 120.

The SCE 140 provides security against algorithmic and physical forms ofintrusion. For example, the separation between the GCE 120 and the SCE140, as well as other attributes of the SCE 140, minimizes thelikelihood of success of an algorithmic attack. To guard againstphysical attack, the SCE 140 may include, or be in communication with,one or more tamper detection devices 234.

The tamper detection devices 234 provide data indicative of actual orpotential tampering with the SCE 140 or elements therein. For example,the tamper detection devices 234 may include switches that indicate thatthe case of the device 110 has been opened. In another example, thetamper detection devices 234 and circuitry may include electricalconductors that, when broken, signal physical tampering. In anotherexample, the tamper detection devices 234 may include sensors. Forexample, temperature sensors, light sensors, voltage measurementdevices, magnetic field sensors, ionizing radiation sensors, ultrasonicsensors, and so forth may provide data that is indicative of tampering.The tamper detection devices 234 may be used to detect tampering ofcomponents that are part of a single die, a circuit board, an assembly,the SCE 140, and so forth. For example, the secure I/O devices 112 mayinclude tamper detection devices 234.

In some implementations, the SCE 140 or portions thereof may beconfigured to self-destruct or otherwise be rendered unusable responsiveto tampering. For example, responsive to a determination of tampering,voltage exceeding a threshold value may be passed through at least aportion of the circuitry in the SCE 140, rendering the circuitryunusable. In another example, responsive to a determination oftampering, storage media may be erased, overwritten, randomized, and soforth.

The SCE 140 may include one or more smart cards 104. The smart card 104may be integral with the SCE 140, may be removeable, or may bewirelessly connected. The smart card 104 may include one or more of acryptoprocessor 238 or a secure encrypted memory 240. For example, thecryptoprocessor 238 may be configured to provide one or morecryptographic functions. The secure encrypted memory 240 may be used tostore one or more secret data 242, such as private keys 282, passcode244 values, and so forth. The private keys 282 may include asset privatekeys. In some implementations the secrets 242 may include thecryptographic data.

Communication with the smart card 104 may be established using one ormore electrical contacts, or wirelessly using electromagnetic radiation,magnetic fields, sound, and so forth. For example, the communicationinterfaces 232 may include an interface that requires electrical contactwith the smart card 104 and is compliant with at least a portion of theInternational Organization for Standards (ISO) and InternationalElectrotechnical Commission (IEC) ISO/IEC 7816 standard. In anotherexample, the communication interfaces 232 may include a wirelessinterface that is compliant with at least a portion of the ISO/IEC14443.

The smart card 104 may also include a physically unclonable function(PUF) 246. The PUF 246 may be based on some characteristic of the smartcard 104 or a component therein that exhibits physical variation duringfabrication. The PUF 246 may be used to produce data that is unique tothat particular smart card 104, but is considered stable with respect toa specified range of environmental conditions. Physical variablefeatures such as the distribution of coatings, arrangement of acrystalline lattice, arrangement of magnetic particles, and so forth maybe used to generate the PUF 246. In some implementations, the PUF 246may be used as a private key 282, or as random seed to generate aprivate key 282.

As shown in FIG. 2 , the SCE 140 includes one or more memories 248. Thememory 248 may comprise one or more CRSM. As described above, the CRSMmay be any one or more of an electronic storage medium, a magneticstorage medium, an optical storage medium, a quantum storage medium, ora mechanical computer storage medium, and so forth. The memory 248provides storage of computer-readable instructions, data structures,program modules, and other data for the operation of the SCE 140. A fewexample functional modules are shown stored in the memory 248, althoughthe same functionality may alternatively be implemented in hardware,firmware, or as a system on a chip (SoC).

The memory 248 may comprise a stack 142. As described above, the stack142 may comprise one or more static buffers 144. Various techniques maybe used to prevent unwanted manipulation of data within the stack 142,such as using different static buffers 144 to store a data payload fromthe payload data 134, working registers, memory pointer values, and soforth.

The memory 248 may include at least one operating system (OS) module250. The OS module 250 is configured to manage hardware resource devicessuch as the communication interfaces 232, the secure I/O devices 112,and provide various services to applications or modules executing on theprocessors 228. For example, the OS module 250 may implement a variantof the Linux operating system, such as Free BSD.

The memory 248 may store one or more of the following modules. Thesemodules may be executed as foreground applications, background tasks,daemons, and so forth. These modules may include one or more of apairing module 254, a secure UI module 162, a condition module 258, acryptography module 168, or other modules 262.

Also stored in the memory 214 may be a data store 264. The data store264 may use a flat file, database, linked list, tree, executable code,script, or other data structure to store information. The data store 264may include one or more of configuration data 266, pairing data 268,condition data 270, boundary values 272, contact data 274, or other data276. For example, the configuration data 266 may comprise settingsassociated with operation of the OS module 250, data indicative of thelimits imposed by the communication module 252, and so forth.

The communication module 252 may use one or more of the communicationinterfaces 232 to provide communication between the SCE 140 and the GCE120. The communication module 252 may implement mailbox functionality,restricting the type of data that may be transferred between the SCE 140and the GCE 120. The communication module 252 may restrict communicationbased on frequency of data transfer, size of the data, type of databeing transferred, implement a limited set of instructions, and soforth. For example, if the communication module 252 receives requestdata 132 from the GCE 120 that is too large, the communication module252 may erase the request data 132. In another example, thecommunication module 252 may suspend communications when a number ofmessages per unit time exceeds a threshold value. In someimplementations, if the communication module 252 or other module detectsactivity that exceeds one or more thresholds, mitigating actions may betaken. These mitigating actions may include, but are not limited to,erasure of the secure encrypted memory 240, rendering one or morecomponents of the SCE 140 inoperable, and so forth. For example, if thenumber of invalid instructions processed by the communication module 252exceeds a threshold count within a predetermined period of time, thesecure encrypted memory 240 may be erased. Likewise, the communicationmodule 252 may impose limits on outbound communication to the GCE 120.

The pairing module 254 may generate or update the pairing data 268.Pairing indicates an established and trusted relationship between thedevice 110 and another device or system. The other device may be anotherdevice 110. The pairing module 254 may be configured to participate in apairing process. For example, the communication module 252 may receivemessage data from the GCE 120 that comprises data associated withpairing, such as a source identifier, a source address, a public key,and so forth. The communication module 252 passes the message data tothe pairing module 254 for processing. The pairing module 254 mayimplement one or more techniques for pairing. For example, the pairingmodule 254 may utilize a Diffie-Hellman key exchange. In oneimplementation, a first device 110(1) may comprise the GCE 120 while asecond device 110(2) may comprise the SCE 140. The first device 110(1)may be paired with the second device 110(2). After successfully pairing,the first device 110(1) may utilize the SCE 140 of the second device110(2).

The secure UI module 162 provides the secure user interface 114 via thesecure I/O devices 112 in the SCE 140. For example, the secure UI module162 may accept user input from a secure input device to provideinformation that is absent from, or replace information in, the requestdata 132. The secure UI module 162 may present other user interfaces toperform other operations, such as pairing with another device,confirming transfer, and so forth.

During operation, some data may be transferred over the network 190,with the GCE 120 providing communication to the SCE 140 of the device110. For example, the SCE 140 of the device 110 may use thecommunication capabilities of the GCE 120 to receive signed abstractiondata from a server.

The condition module 258 may be used to assess incoming data, such asthe request data 132 or other message data. The condition module 258 mayassess values of the incoming data against one or more of the pairingdata 268 or the condition data 270 and corresponding boundary values272.

In some implementations, the condition module 258 may be configured todisregard all message data that is not associated with a paired deviceas indicated in the pairing data 268. For example, a paired device sendsmessage data to the device 110 for signing. In another example, thecondition module 258 may disregard traffic from devices other than thosespecified in proposal data that has been previously sent. The conditionmodule 258 checks a source address, signature data, or other values inthe message data to determine if the message data is associated withpairing data 268 indicative of a pairing that is still in force.

Each pairing, as indicated in the pairing data 268, may have one or moredifferent rules or conditions associated with that pairing. Theseconditions may specify limits designated by the user 102, administrator,and so forth.

Continuing the earlier example, after determining a valid pairingexists, the condition module 258 then compares one or more other valuesof the message data to determine if they satisfy one or more of theconditions specified in the condition data 270. The condition data 270may indicate particular fields of data and the corresponding boundaryvalues 272 for those fields. For example, the field may be “type ofcurrency” and the boundary value 272 may be “ETH”.

The condition data 270 may be used to specify one or more of a type ofasset that is permitted, a type of transaction that is permitted, amaximum number of signed messages within a specified interval of time, amaximum quantity of assets in a single transaction, a minimum quantityof assets in a single transaction, or a maximum quantity of assetstransferred per interval of time, and so forth. In otherimplementations, other conditions may be specified with correspondingboundary values 272.

The conditions specified by the condition data 270 may include arequirement for verification by the user 102 before the cryptographicoutput data 170 is determined. For example, the secure UI module 162 maybe used to accept input from the user 102 indicative of approval todigitally sign data. In one implementation, the input provided by theuser 102 may comprise a passcode 244 that, when entered using the secureinput device and subsequently validated, is used to access one or moreof the private keys 282. For example, the passcode 244 may be used toauthorize or otherwise indicate use of a “blind” private key 282. Inanother implementation, instead of or in addition to the passcode 244, aremoveable smart card 104 may be required. With this implementation, theSCE 140 utilizes the removeable smart card 104 as a form of secondfactor authentication.

The cryptography module 168 performs one or more cryptographicfunctions. These cryptographic functions may include, but are notlimited to, cryptographic signing operations, memory operations,cryptographic transformation operations, and so forth. For example,these may include private key generation, creation of one or more piecesof a private key 282 for sharing, hierarchically deterministic addressgeneration, digital signing, hash generation, multiple signaturesigning, encryption, decryption, and so forth. For example, thecryptographic functions may include an implementation of secret sharing,such as described by Adi Shamir, George Blakely, and so forth, thatallows for a secret 242 to be divided into several pieces that may thenbe distributed. The private key 282 may then be determined using thepieces, or a subset of those pieces. In another example, thecryptographic functions may produce, based on one or more of the privatekeys 282, a digital signature that is used to create the signed data.

In some implementations, one or more of the cryptographic functions maybe performed at least in part by the smart card 104. For example, acryptographic processor (cryptoprocessor) on the smart card 104 may beused to perform the cryptographic functions.

The memory 248 may store contact data 274. The contact data 274comprises information about one or more participants or contacts thatmay be parties to a transaction involving the device 110. For example,the contact data 274 may comprise information such as the names andcryptocurrency addresses, pictures, and so forth of friends, family,vendors, and so forth that the user 102 wants to transfer assets to. Insome implementations, the specific data 158 may comprise the contactdata 274.

As described above, public key values, cryptocurrency addresses, andother data associated with transactions involving cryptography can betroublesome for the user 102 to deal with. Humans may have difficultyworking with long sequences of letters and numbers. For example, humansmay have difficulty discerning small differences between those strings,remembering a cryptocurrency address, and so forth. As a result, thereis the potential for the user 102 to incorrectly select onecryptocurrency address when another is intended, or otherwise introduceerrors into the process of generating the signed data.

The abstracted request data 160, or a portion thereof, may be presentedin the secure user interface 114. By presenting the abstracted requestdata 160, the user 102 is quickly and easily able to confirm theirintent, and more easily determine unwanted or incorrect transactions. Asa result, overall security of the system 100 is improved. In otherimplementations, the request data 132 may be presented in the secureuser interface 114.

In some implementations, processing of the request data 132 by the SCE140 may use a stack-based architecture with several static buffers toimprove security. These static buffers may include one or more of a datapayload buffer, a stack buffer, or a working register buffer. Thesebuffers may be the same size, or may differ in size from one another.The buffer size is static in that it is specified in advance and may notbe changed during processing of request data 132. In someimplementations, the request processing module 126 may enforce limits onthe determination of the request data 132 to enforce operation withinthese buffers. For example, the request processing module 126 may usethe schema data 128 to determine request data 132 that comports withCBOR. In another example, the request processing module 126 maydetermine the request data 132 such that expected intermediateoperations, data, and so forth that are associated with the generationof the cryptographic output data 170 will operate within the confines ofthe statically allocated buffers.

The other modules 262 may provide other functions.

In one implementation, the SCE 140 may comprise the Kinetis K81microcontroller unit (MCU) from NXP Semiconductors N.V. of Eindhoven,the Netherlands. In other implementations, the SCE 140 may compriseother devices.

FIG. 3 illustrates a portion 300 of blockchain data 194, according toone implementation. The techniques described in this disclosure allowfor use of different protocols. Some of these protocols may involvetransactions involving different distributed ledgers, also known asblockchains.

A blockchain comprises a system that utilizes a network of peers thatprovide distributed data storage and processing of blockchain data 194that provides a canonical record. The blockchain data 194 maintainsinformation about a current state as well as how that current state wasarrived at.

To maintain a deterministic state at all times, data is recorded intothe database in blocks 302(1), 302(2), 302(3), . . . , 302(B). Eachblock 302 comprises a block header that includes a previous hash 304, anonce 306, a transaction root 308, and a timestamp 310. The block 302may include payload data, such as details of a transaction, contractparameters, and so forth. In some implementations, the block 302 mayinclude other data that facilitates proof and verification of thetransactions which are contained in that block 302 as well as theprecedence of the existence of that block 302 relative to other blocks302 in the blockchain data 194. Blocks 302 are linked together over timeby recording the previous hash 304 of the previous block 302 in thesubsequent block 302. For example, block 302(2) includes the previoushash 304(2) that is derived from the data in the block 302(1). Theprevious hash 304 of a given block 302 may be constructed of a hash ofdata contained in the block 302 as well as a nonce 306 which forms ablock hash which meets the requirements of consensus of the givenblockchain.

Transaction data 312 is hashed to produce a transaction hash 314. Aplurality of transaction hashes 314 may then be hashed again in adeterministic way with one another, such as using a Merkle tree, to forma hash 316, until they are all represented by a single hash 316 which isstored as the transaction root 308. The hashing process allows theverification of the existence of all transaction data 312 in a block 302because the transaction data 312 can be shown to be part of thetransaction root 308 recorded in the block header in the block 302. Insome implementations, the transaction data 312 may include a messagecryptographically signed by the current owner of an asset transferringthe asset to another address. For example, the user 102 may use thedevice 110 to create, based on a private key stored in the smart card104, the cryptographic output data 170 comprising a digitally signedmessage that is then used as transaction data 312 which is subsequentlycommitted to the blockchain data 194. Continuing the example, thetransaction data 312 may comprise at least a portion of the formattedoutput data 182. The transaction data 312 submitted to the blockchainservers 192 for processing comports with the protocol associated withthat system.

The ownership of assets or other entities recorded by the blockchaindata 194 is determined by the ability of a participant tocryptographically sign a message which moves assets from a first accountto a second account. The ability to create the signed message data whichwill be honored by the blockchain servers 160 may be predicated on theability to sign the message data with a private key 282 that correspondsto a source account or an address of the assets.

FIG. 4 illustrates at 400 block diagrams of data associated withoperation of the system such as transaction input data 124, schema data128, available secure function(s) 130 information, and request data 132,according to one implementation. The data is depicted in a table formatfor ease of illustration, and not as a limitation. In otherimplementations other data structures may be used.

The transaction input data 124 may comprise information that isindicative of one or more transactions that utilize one or morecryptographic functions to complete. In this illustration, thetransaction input data 124 may be representative of a cryptocurrency orother digital asset transfer, and comprises a protocol identifier 402, atype 404, a source address 406, a destination address 408, and aquantity or value 410. Other information may be included, but is notshown. For example, executable code associated with a smart contract maybe included.

The schema data 128 may specify the grammar, syntax, location, format,and so forth of various elements for a particular protocol. For example,schema data 128(2) may specify the elements of data associated with aBitcoin transaction, formatting, cryptographic operations required, datatypes, and so forth. The schema data 128 may also include informationindicative of the cryptographic functions that are utilized. In someimplementations the schema data 128 may include information such as thenumber base and precision of number values associated with thatprotocol.

The available secure function(s) 130 comprises information indicative ofthe capabilities of the SCE 140 or portions thereof. In someimplementations, the available secure function(s) 130 may includeinformation such as a smart card identifier 450, such as a serial numberof a particular smart card 104, version number, hash value, or otherinformation. The smart card identifier 450 or other data may be used tospecify or refer to the particular functions that are available withinthe SCE 140.

The available secure function(s) 130 may comprise information aboutfunctions that may be specified in the request data 132 to determine thecryptographic output data 170. For example, the determination of thecryptographic output data 170 may include the composition and signing ofmessages which adhere to specific end use definitions or protocols.Composition may comprise processing at least a portion of the payloaddata 134 in accordance with the instruction data 136 using at least aportion of the available secure functions 130.

The available secure function(s) 130 may include information that refersto functions such as serialization functions available 452,transformation functions available 454, comparator functions available456, signature functions available 458, and so forth.

The serialization functions available 452 may support variousserialization/deserialization operations such as recursive length prefix(RLP), CBOR, concatenation, and so forth that may be used during messagecomposition. Examples of serialization commands that may be included inthe request data 132 may include one or more of OP_RLP_ENCODE,OP_CBOR_ENCODE, OP_PUSH, OP_POP, OP_FLIP, OP_LENGTH, or OP_CONCAT, andso forth.

The transformation functions available 454 may include cryptographictransformations that may be applied to one or more parts of a payload ormessage during message composition. The transformation functionsavailable 454 may support transformations such as cryptographic hashingalgorithms such as SHA256, Keccack256, MD160, Base64, and so forth.Examples of transformation commands that may be included in the requestdata 132 may include one or more of OP_SHA256, OP_KECCACK256, OP_MD160,OP_SS58, OP_HEXTODEC, OP_DECTOHEX, or OP_BASE64, and so forth.

The comparator functions available 456 may include operations forcomparison of data, such as “=”, “<”, “>”, and so forth. Examples ofcomparator commands that may be included in the request data 132 mayinclude one or more of OP_EQUAL, OP_LESSTHAN, or OP_GREATERTHAN, and soforth.

The signature functions available 458 may include cryptographicsignature algorithms that may be used to cryptographically sign at leasta portion of one or more of a payload or message during composition. Thesignature functions available 458 may support cryptographic signaturealgorithms such as elliptical curve digital signature algorithms (ECDSA)secp256k1, secp256r1, ed25519, and so forth. Examples of signaturecommands that may be included in the request data 132 may include one ormore of OP_SECP256k1, OPSECP256R1, or OP_ED25519, et cetera which allowsignatures to be made on some or all portions of the payload or messageduring composition.

The request data 132 may comprise payload data 134 and instruction data136. The payload data 134 may comprise one or more values that may beused as input to or operands for composition of a message. For example,the payload data 134 may comprise a value of a source address, a valueof a destination address, and so forth. The instruction data 136comprises one or more instructions such as operators, instructions,values, and so forth that are associated with operating one or more ofthe processor(s) 228, or cryptoprocessor(s) 238, and so forth. In someimplementations, the instruction data 136 may comprise a script that maybe used to execute one or more of the available secure functions 130 onthe cryptoprocessor 238, use of the secrets 242, input values forprocessing, and so forth.

In the implementation depicted here, the payload data 134 and theinstruction data 136 are separate portions of the request data 132. Inother implementations, the payload data 134 and the instruction data 136may be intermixed.

The request data 132, or a portion thereof, may be represented with aspecified formatting to be processed by the SCE 140. For example, therequest data 132 may be formatted as JavaScript Object Notation (JSON),concise binary object representation (CBOR), and so forth. Thisformatting may include some features to improve intelligibility forhuman operators viewing the data.

The request data 132 may permit definition and use of tags that arespecified by the GCE 120 and refer to data in the payload data 134. Forexample, the tags in the payload data 134 may comprise “<toAddress>”,“<fromAddress>”, “<chainId>”, “<value>”, and so forth. These tags can bereferenced in the instruction data 136 to move data onto the stack 142and then operate on the data using one or more of the available securefunctions 130 to determine the cryptographic output data 170.

In some implementations, examples of the following request data 132, orportions thereof, may be used during operation of the system 100.

//Ethereum {  “Derivation Path” : “ m/44'/60'/0'/0/0 ”,  “DestAddress” :“0×818a2266c12b15d853de5adc2f2c6acc1d8920b7”,  “ChainId” : “<ID>”, “Native encoding” : “RLP”,  “Transformation” : “keccak256”, “Curve” : “secp256k1”,  “Payload” : “<encoded data>”, “Value” : “0×01cba1761f7ab9870c”,  “Gas Price” : “0×1fe5d61a00”, “Gas” : “0×34e97”,  “Data” : “0×17e...”,  “RSV” : {   “r” : null,  “s” : null,   “v” : “0×01”  },  “Nonce” : “0×02” }

Example 1

//Bitcoin {  “Derivation Path” : “ m/44'/0'/0'/0/0 ”, //Derivation Path “Dest Address” : “3Et5JhPaQrjTMVTq31p38ydbSwE6Q52xAb”, //Dest Address “ChainId” : “<ID>”,  “Native Encoding” : “BTC” //Native encoding “Transformation” : “base58” //Transformation “Curve” : “Secp256k1” //SigningCurve “Payload” : “<encoded data>” //Transaction Payload “Value” : “3.68” //Value “Transaction Fees” : “0.001” //Transaction fees “Data” : “” //Transaction data, user readable }

Example 2

  //Cardano {  “Derivation Path” : “m/44'/1815'/0'/0/0” , //DerivationPath  “Dest Address” :“37btjrVyb4KDXBNC4haBVPCrro8AQSHbdCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na”, //Dest Address “ChainId” : “<ID>”,  “Native Encoding” : “CBOR” “Transformation” : “blake2b”  “Curve” : “ed25519” “Payload” : “<encoded data>”  “Value” : “3.68” “Transaction Fees” : “0.001”  “Data” : “” }

Example 3

{  “EIP155Mode” : “false”,  “EIP155Mode” : 0,  “path” : {  “pathDepth” : 5,   “purpose” : {“u32” : 0×80000000 + 44},  “coin” : { “u32” : 0×80000000 + 60},  “account” : {“u32” : 0×80000000},   “change” : {“u32” : 0},  “addr” : {“u32” : 5},  },  “nonce” : 5,  “gasPrice” : 1000000000, “gasLimit” : 100000,  “addrTo” : {   “u8” : [   0×76, 0×9f, 0×78, 0×37, 0×30, 0×e4, 0×99, 0×94, 0×f7, 0×24,   0×06, 0×98, 0×98, 0×f8, 0×73, 0×8b, 0×fd, 0×40, 0×6d, 0×fd,   ],  }, “value” : [   0×00, 0×00, 0×f4, 0×44, 0×82, 0×91, 0×63, 0×45, 0×00,0×00,   0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,  0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,  0×00, 0×00,  ] ,  “dataSz” : 6,  “data” : [  0×01, 0×02, 0×03, 0×04, 0×05, 0×06,  ] , “num_elements_to_encode” : 6,  “GARTscript” : [  0×01, 0×02, 0×01, 0×02, 0×01, 0×02, 0×01, 0×01, 0×02, 0×01,  0×01, 0×03, 0×04, 0×05, 0×00,  ]  “GARTmap” : [  “nonce”, “gasPrice”, “gasLimit”, “addrTo”, “value”,“data”, “num_elements_to_encode”,  ] }  <nonce> OP_STACK_PUSH, OP_FLIP_BYTES,  <gasPrice> OP_STACK_PUSH,  OP_FLIP_BYTES, <gasLimit> OP_STACK_PUSH,  OP_FLIP_BYTES,  <addrTo> OP_STACK_PUSH, <value> OP_STACK_PUSH,  OP_FLIP_BYTES,  <data> OP_STACK_PUSH <num_elements_to_encode> OP_STACK_PUSH  OP_RLP_ENCODE,  OP_KECCAK256, OP_SECP256K1_SIGN,  OP_NOP

Example 4

FIG. 5 illustrates at 500 block diagrams of abstraction data 154 andabstracted request data 160 that may be used by the secure userinterface 114 to present secure output that facilitates userreadability, according to one implementation. The data is depicted in atable format for ease of illustration, and not as a limitation. In otherimplementations other data structures may be used.

The abstraction data 154 may comprise data that specifies a relationshipbetween first data and second data. In some implementations, thisrelationship may be deemed to be semantically equivalent. For example,“XKC” may be deemed to be equivalent to “XKCoin”. In someimplementations the abstraction data 154 may comprise one or moreregular expressions (regexes) and associated parameters. These regexesmay be used to process the request data 132 to determine the abstractedrequest data 160 by selectively replacing strings present in the requestdata 132 with predefined strings.

The abstraction data 154 may comprise one or more of general data 156 orspecific data 158. The general data 156 may comprise information that isapplicable to a plurality of users. For example, the general data 156may associate the identifiers for various cryptocurrencies to a longername.

The specific data 158 may comprise information that is applicable to aparticular user or set of users. For example, the specific data 158 mayassociate an account address with a text string such as “Blake'saccount”. In some implementations, the specific data 158 may be storedwithin the secure encrypted memory 240 of a particular smart card 104.For example, the source addresses associated with private keys 282stored within that secure encrypted memory 240 may be stored as specificdata 158 in the secure encrypted memory 240.

In some implementations, the abstraction data 154 may be obtained from asource that is outside of the SCE 140. To reduce the likelihood of thatabstraction data 154 being tampered with, the abstraction data 154 maybe one or more of encrypted, digitally signed, and so forth. In thisillustration, the general data 156 may be provided by an externalservice, such as a trusted provider as signed general data 502. Thetrusted provider may digitally sign the general data 156 to facilitatedistribution and detect tampering with the general data 156. Forexample, the signed general data 502 may comprise the general data 156being cryptographically signed using a certificate authorizationsignature 504 from a trusted certificate authority. If the digitalsignature is determined to be valid by the SCE 140, the general data 156may be stored in the SCE 140 and subsequently used. If the digitalsignature is determined to not be valid, one or more actions may beperformed such as deleting the general data 156, sending an errormessage, presenting a notification using the secure user interface 114,and so forth.

The abstracted request data 160 is based on the request data 132, asmodified within the SCE 140 based on the abstraction data 154 to provideinformation that may be more intelligible to the user 102. For example,64 bit hexadecimal addresses may be replaced with predefined stringsthat represent names or mnemonics, characters in a language other than aspecified language may be replaced, highlighted, enlarged, and so forth.

FIG. 6 illustrates at 600 adding abstraction data 154 to the system,according to one implementation. As described above, the abstract module152 may use abstraction data 154 to process the request data 132received from the GCE 120 and determine abstracted request data 160. Theabstraction data 154 may be received from a source that is external tothe SCE 140 as shown at 602, may be determined based on secure inputprovided within the SCE 140 as shown at 604, or a combination thereof.

At 602, signed general data 502 may be sent from a server to the device110. The GCE 120 may receive the signed general data 502. The GCE 120may send the signed general data 502 to the SCE 140. The SCE 140 mayattempt to validate the digital signature of the signed general data502. In this illustration, the digital signature has been deemed to bevalid, and the secure I/O device(s) 112 are used to present secure useroutput 164 in the secure user interface 114(1). As shown, the secureuser interface 114(1) presents that the abstraction data has beenreceived, who it is from, presents an example of the abstractionspecified, and requests secure user input 166 to confirm that this is tobe used by the abstract module 152. If the user 102 indicates acceptanceby providing valid secure user input 166, such as by entering a validpasscode 244, the general data 156 included in the signed general data502 may be stored, and subsequently used by the abstract module 152.

At 604, abstraction data 154 is added to the SCE 140 based at least inpart on secure user input 166. In this illustration, the secure userinterface 114(2) asks the user if they wish to associate a particulardestination address with an arbitrary text string that may be moreintelligible to the user 102. If the user 102 indicates acceptance byproviding valid secure user input 166, such as by entering a validpasscode 244, the specific data 158 may be stored, and subsequently usedby the abstract module 152.

FIG. 7 at 700 illustrates presentation of request data 132 at 702 andabstracted request data 160 at 704 by the secure user interface 114,according to one implementation. During operation, the user 102 may gaininsight as to the transaction that is pending within the SCE 140 byusing the secure user interface 114.

At 702, the secure user interface 114(3) presents at least a portion ofthe request data 132. As described above, the request data 132 may beconstructed such that it is intelligible to a user 102. This allows theuser 102 to see, in the secure user interface 114, the request data 132as produced by the request processing module 126. For example, severalcomplex address values are shown. However, some structures of requestdata 132 may be redundant to some users, less intelligible to someusers, and so forth.

At 704, the secure user interface 114(4) presents at least a portion ofthe abstracted request data 160. This allows the user 102 to see, in thesecure user interface 114, the abstracted request data 160 as producedby the abstract module 152. In comparison to the request data 132 shownin the secure user interface 114(3), the transaction has beencharacterized as a “transfer”, addresses have been replaced forpresentation with previously specified data, and so forth, improvingintelligibility to the user 102. By using the abstract module 152, theabstracted request data 160 may replace, for the purposes ofpresentation by the secure user interface 114, many lines of the requestdata 132 with a more intelligible and aggregated representation.

While the user interfaces are depicted in this illustration as visualuser interfaces, in other implementations other modalities may be usedinstead of, or in addition to, visual. For example, information may bepresented audibly to the user 102, such as via text-to-speech, audiofiles, and input may be accepted by a speech-to-text system. In anotherexample, information may be presented to the user via a haptic userinterface and input may be accepted by one or more buttons, motionsensors, and so forth. In other examples, the user interface may utilizea human-machine interface that interfaces with at least a portion of theuser's 102 anatomy, a virtual reality user interface, and so forth.

FIG. 8 is a flow diagram 800 of a process for processing transactioninput to determine formatted output data 182, according to oneimplementation. The process may be implemented at least in part by thedevice 110. In this illustration, various operations are described withrespect to particular environments. For example, some operations aredescribed with respect to the GCE 120, while others are in the SCE 140.In other implementations, at least some of these operations may beperformed in the other environments, or elsewhere. For example, a firstdevice 110(1) may comprise the GCE 120 that uses the network 190 tocommunicate with a second device 110(2) that comprises the SCE 140. Insome implementations, a successful pairing, such as using the pairingmodule 254 to determine pairing data 268, may be required before the SCE140 of the second device 110(2) will respond to messages from the GCE120 of the first device 110(1). In some implementations, one or moreoperations may be omitted, some operations may be consolidated, and soforth.

At 802 transaction input data 124 is determined within the GCE 120. Forexample, the user interface module 122 may be used to accept at least aportion of the transaction input data 122 from one or more I/O devices212, from a paired device that is in communication with the GCE 120,from the network 190, and so forth. The transaction input data 124 maybe indicative of a transaction that uses one or more cryptographicfunctions, cryptographic data such as secrets 242, and so forth.

At 804 the GCE 120 determines the available secure functions 130 of theSCE 140. For example, the GCE 120 may send a request to the SCE 140 forthe available secure functions 130(1), a smart card identifier 450 of acurrently connected smart card 104, and so forth. Responsive to therequest, the SCE 140 may respond with one or more of a version number orother identifier that is indicative of a particular set of availablesecure functions 130, the smart card identifier 450, a list of availablesecure functions 130, or other information. For example, the SCE 140 mayreturn a firmware version number that is used by the GCE 120 to retrievea previously stored list of the available secure functions 130. In someimplementations, this operation may be omitted. In the event the requestdata 132 calls for functionality that the SCE 140 is unable to perform,an error may be returned.

At 806 the schema data 128 associated with the transaction input data124 is determined by the GCE 120. For example, the request processingmodule 126 may parse the transaction input data 124 to determine aprotocol identifier. Based on the protocol identifier, particular schemainformation about the associated protocol is retrieved.

At 808, the GCE 120 determines request data 132 based on the transactioninput data 124 and the schema data 128. For example, the requestprocessing module 126 may use the schema data 128 associated with theparticular protocol identifier to parse the transaction input data 124and generate the request data 132 based on the transaction input data124. The GCE 120 may then send the request data 132 to the SCE 140.

In some implementations the available secure functions 130 may be usedto determine the request data 132. For example, if the schema data 128permits alternative cryptographic transformations that may be used, therequest processing module 126 may use the alternative supported by thecryptoprocessor 238 in the available smart card 104 to determine therequest data 132.

In some implementations, the GCE 120 may use an API to provide therequest data 132 to the SCE 140.

At 810 the SCE 140 determines abstraction data 154 that is associatedwith the request data 132. For example, the abstract module 152 maydetermine the protocol identifier indicated in the request data 132 andretrieve one or more regexes that are associated with that protocol.

In other implementations, other information may be used to determine theabstraction data 154 associated with the request data 132. For example,the GCE 120 may maintain a copy of the abstraction data 154 to determineone or more retrieval key values or index values associated with theparticular portion of the abstraction data 154 that is deemed relevant.These key/index values may be included with request data 132 and thenused by the SCE 140 to receive corresponding abstraction data 154. Inthe event the key/index values are erroneous or have been tampered with,such tampering may be detected by the SCE 140. For example, the abstractmodule 152 may only permit retrieval of related index values, may onlyspecify a root level index value, and so forth. In the event of anincorrect index value, a failure would result. A failure may result intermination of the current transaction, presentation of an errormessage, self-destruction, or other actions.

At 812, based on the abstraction data 154 associated with the requestdata 132 and the request data 132, the SCE 140 determines the abstractedrequest data 160. For example, the abstract module 152 may use one ormore regexes to modify a copy of the request data 132 to determine theabstracted request data 160.

At 814 the SCE 140 uses a secure output device to present secure useroutput 164 in the secure user interface 114. This secure user output 164may be at least a portion of one or more of the request data 132, or theabstracted request data 160, and so forth. For example, the secure userinterface 114 may be used to present the abstracted request data 160.The presentation of the secure user output 164 mitigates the risk of anunintended signing by providing the user 102 with the opportunity toconfirm one or more aspects of the proposed transaction.

At 816 the SCE 140 uses a secure user input device to determine secureuser input 166. For example, the secure user input 166 may comprise oneor more values associated with the transaction, a passcode 244 or otherinformation to confirm the transaction is to proceed, or otherinformation.

At 818 the SCE 140 determines cryptographic output data 170 based on therequest data 132. For example, the request data 132 may includeinstructions in the instruction data 136 to perform one or moreoperations on the payload data 134 using the cryptoprocessor 238 tocompose the cryptographic output data 170. The cryptographic output data170 may be sent to the GCE 120.

At 820 the GCE 120 determines, based on the cryptographic output data170, the formatted output data 182. For example, the output processingmodule 180 may accept as input the cryptographic output data 170 and usethe schema data 128 to generate the formatted output data 182 accordingto a specified protocol.

At 822 the GCE 120 sends the formatted output data 182. For example, theformatted output data 182 may be sent to a blockchain server 192. Theblockchain server 192 may then process the formatted output data 182 andperform one or more transactions associated with the blockchain data194. In some implementations, the formatted output data 182 may be sentto a device other than that comprising the GCE 120.

In some implementations, one or more operations may be omitted orbypassed. For example, the operations of 810 and 812 may be omitted, andthe process may proceed to 814 or 818. In another example, theoperations of 810-816 may be omitted and the process may proceed to 818.In still another example, the cryptographic output data 170 may be usedwithout further processing, and operation 820 may be omitted and thecryptographic output data 170 may be sent instead.

The processes discussed herein may be implemented in hardware, software,or a combination thereof. In the context of software, the describedoperations represent computer-executable instructions stored on one ormore non-transitory computer-readable storage media that, when executedby one or more processors, perform the recited operations. Generally,computer-executable instructions include routines, programs, objects,components, data structures, and the like that perform particularfunctions or implement particular abstract data types. Those havingordinary skill in the art will readily recognize that certain steps oroperations illustrated in the figures above may be eliminated, combined,or performed in an alternate order. Any steps or operations may beperformed serially or in parallel. Furthermore, the order in which theoperations are described is not intended to be construed as alimitation.

Embodiments may be provided as a software program or computer programproduct including a non-transitory computer-readable storage mediumhaving stored thereon instructions (in compressed or uncompressed form)that may be used to program a computer (or other electronic device) toperform processes or methods described herein. The computer-readablestorage medium may be one or more of an electronic storage medium, amagnetic storage medium, an optical storage medium, or a quantum storagemedium, and so forth. For example, the computer-readable storage mediamay include, but is not limited to, hard drives, optical disks,read-only memories (ROMs), random access memories (RAMS), erasableprogrammable ROMs (EPROMs), electrically erasable programmable ROMs(EEPROMs), flash memory, magnetic or optical cards, solid-state memorydevices, or other types of physical media suitable for storingelectronic instructions. Further, embodiments may also be provided as acomputer program product including a transitory machine-readable signal(in compressed or uncompressed form). Examples of transitorymachine-readable signals, whether modulated using a carrier orunmodulated, include, but are not limited to, signals that a computersystem or machine hosting or running a computer program can beconfigured to access, including signals transferred by one or morenetworks. For example, the transitory machine-readable signal maycomprise transmission of software by the Internet.

Separate instances of these programs can be executed on or distributedacross any number of separate computer systems. Thus, although certainsteps have been described as being performed by certain modules,devices, software programs, processes, or entities, this need not be thecase, and a variety of alternative implementations will be understood bythose having ordinary skill in the art. For example, the functionalityprovided by one module may be incorporated into another.

Additionally, those having ordinary skill in the art will readilyrecognize that the system and techniques described above can be utilizedin a variety of devices, environments, and situations.

Although the subject matter has been described in language specific tostructural features or methodological acts, it is to be understood thatthe subject matter defined in the appended claims is not necessarilylimited to the specific features or acts described. Rather, the specificfeatures and acts are disclosed as illustrative forms of implementingthe claims.

What is claimed is:
 1. A system comprising: a first device comprising: afirst general computing environment (GCE) comprising: a first networkinterface; a first memory storing first computer-executableinstructions; and a first processor in communication with the firstnetwork interface and the first memory, the first processor executingthe first computer-executable instructions to: determine transactioninput data indicative of a transaction using one or more cryptographicfunctions; determine schema data associated with the transaction inputdata; determine, based on the transaction input data and the schemadata, request data comprising payload data and instruction data; sendthe request data to a first secure computing environment (SCE); receive,from the first SCE, cryptographic output data; determine, based on theschema data and the cryptographic output data, formatted output data;and send, using the first network interface, the formatted output data;and the first SCE comprising: a first secure output device; a firstsecure input device; a first secure encrypted memory; a firstcryptoprocessor; and a second processor in communication with: the firstprocessor, the first secure output device, the first secure inputdevice, the first secure encrypted memory, and the firstcryptoprocessor, and the second processor executing secondcomputer-executable instructions to: receive the request data; processthe payload data, according to the instruction data, using the firstcryptoprocessor to determine cryptographic output data; and send thecryptographic output data to the first GCE.
 2. The system of claim 1,wherein the first SCE utilizes one or more static buffers to process therequest data.
 3. The system of claim 1, the second processor executingthe second computer-executable instructions to: determine abstractiondata associated with the request data; determine, based on theabstraction data and the request data, abstracted request data; present,using the first secure output device, at least a portion of theabstracted request data; determine, using the first secure input device,first secure user input; determine the first secure user input is validinput; and wherein the instructions to process the payload data usingthe first cryptoprocessor are responsive to the valid input.
 4. Thesystem of claim 1, wherein the schema data is indicative of one or moreof: grammar associated with a transaction using a first blockchain,syntax associated with the transaction using the first blockchain,number base and precision associated with one or more values of thetransaction using the first blockchain, or a message format.
 5. Thesystem of claim 1, wherein the request data is formatted as a concisebinary object representation (CBOR).
 6. The system of claim 1, thesecond processor executing the second computer-executable instructionsto: receive signed abstraction data comprising abstraction data, whereinthe abstraction data specifies a relationship between first data in therequest data and second data; determine, using the firstcryptoprocessor, that the signed abstraction data is validly signed; andstore the abstraction data in the first secure encrypted memory.
 7. Thesystem of claim 1, the second processor executing the secondcomputer-executable instructions to: determine, using the first secureinput device, first secure user input; determine the first secure userinput is valid input; determine, based at least in part on the validinput, abstraction data, wherein the abstraction data specifies arelationship between first data in the request data and second data; andstore the abstraction data in the first secure encrypted memory.
 8. Thesystem of claim 1, the first processor executing the firstcomputer-executable instructions to: receive, using the first networkinterface, the transaction input data from a second device; and thesecond processor executing the second computer-executable instructionsto: determine, using the first secure input device, first secure userinput; and determine, based on the first secure user input, one or morevalues of the request data.
 9. A computer-implemented method comprising:determining transaction input data, wherein the transaction input datais indicative of a transaction using one or more cryptographicfunctions; determining schema data associated with the transaction inputdata; determining, based on the transaction input data and the schemadata, request data comprising payload data and instruction data; sendingthe request data to a secure computing environment (SCE); and receiving,from the SCE, cryptographic output data.
 10. The computer-implementedmethod of claim 9, further comprising: determining, based on the schemadata and the cryptographic output data, formatted output data; andsending the formatted output data.
 11. The computer-implemented methodof claim 9, further comprising: processing the request data within theSCE to determine the cryptographic output data, the processingcomprising: determining, based on the payload data, a first input;accessing secret data stored in secure encrypted memory of the SCE; andoperating at least one processor within the SCE based on an instructionof the instruction data, wherein the instruction is indicative of acryptographic function, the first input, and the secret data.
 12. Thecomputer-implemented method of claim 9, further comprising: storingabstraction data within the SCE; determining at least a portion of theabstraction data is associated with the request data; determining withinthe SCE, based on the abstraction data and the request data, abstractedrequest data; presenting, using a secure output device associated withthe SCE, at least a portion of the abstracted request data; determining,using a secure input device associated with the SCE, secure user input;determining the secure user input is valid input; and processing therequest data, using the SCE, responsive to the valid input.
 13. Thecomputer-implemented method of claim 9, wherein the schema data isindicative of one or more: grammar associated with a transaction, syntaxassociated with the transaction, number base and precision associatedwith one or more values of the transaction, or a message format.
 14. Thecomputer-implemented method of claim 9, wherein at least a portion ofthe request data is formatted as a concise binary object representation(CBOR).
 15. The computer-implemented method of claim 9, furthercomprising: receiving signed abstraction data comprising abstractiondata; determining, using the SCE, that the signed abstraction data isvalidly signed; and storing the abstraction data within the SCE.
 16. Thecomputer-implemented method of claim 9, further comprising: determining,using a secure input device associated with the SCE, secure user input;determining the secure user input is valid input; determining, based atleast in part on the valid input, abstraction data, wherein theabstraction data specifies a relationship between first data in therequest data and second data; and storing the abstraction data in theSCE.
 17. A system comprising: a first secure computing environment (SCE)comprising: a communication interface; a secure output device; a secureinput device; a secure encrypted memory; and one or more processors incommunication with: the communication interface, the secure outputdevice, the secure input device, and the secure encrypted memory, andthe one or more processors executing first computer-executableinstructions to: receive request data comprising payload data andinstruction data, wherein the instruction data comprises one or moreinstructions; present, using the secure output device, data that isbased at least in part on the request data; determine, using the secureinput device, first secure user input; based at least in part on thefirst secure user input, execute the one or more instructions of theinstruction data to process the payload data and determine cryptographicoutput data; and send, using the communication interface, thecryptographic output data.
 18. The system of claim 17, the one or moreprocessors executing the first computer-executable instructions to:receive, using the communication interface, signed abstraction data;determine that the signed abstraction data is validly signed; store atleast a portion of the signed abstraction data in the secure encryptedmemory; determine the at least a portion of the signed abstraction datais associated with the request data; and determine, based on the atleast a portion of the signed abstraction data and the request data,abstracted request data; wherein the abstracted request data is the datathat is based at least in part on the request data.
 19. The system ofclaim 17, the one or more processors executing the firstcomputer-executable instructions to: determine, using the secure inputdevice, secure user input; determine, based at least in part on thesecure user input, abstraction data; store the abstraction data in thesecure encrypted memory; determine the abstraction data is associatedwith the request data; and determine, based on the abstraction data andthe request data, abstracted request data; wherein the abstractedrequest data is the data that is based at least in part on the requestdata.
 20. The system of claim 17, further comprising: a generalcomputing environment (GCE) comprising: a second communicationinterface; a second memory storing second computer-executableinstructions; and a second processor in communication with the secondcommunication interface and the second memory, the second processorexecuting the second computer-executable instructions to: determinetransaction input data indicative of a transaction using one or morecryptographic functions; determine schema data associated with thetransaction input data, wherein the schema data is indicative of one ormore: grammar associated with a transaction, syntax associated with thetransaction, number base and precision associated with one or morevalues of the transaction, or a message format; determine, based on thetransaction input data and the schema data, the request data; send therequest data to the SCE; receive, from the SCE, the cryptographic outputdata; determine, based on the schema data and the cryptographic outputdata, formatted output data; and send, using the second communicationinterface, the formatted output data.